Many data storage systems maintain persistent metadata in order to reliably be brought back up in the event of improper system shutdown or catastrophic system failure. This is especially true of storage systems that maintain a lookup table or a map table to perform input/output (“I/O”) operations. A lookup table is necessary in systems that implement advanced storage features such as snapshots and thin provisioning.
In order to ensure that data writes that have been signaled as completed successfully to the initiator are not lost on catastrophic system failure, it is necessary to make an update of the lookup table part of the path of an I/O operation. The traditional methods of updating metadata tables, such as a lookup table, is to write the corresponding parts of the table to disk or to maintain a fragmented representation of the table on disk and update it as needed. Both of these methods, however, are costly in terms of I/O performance and the amount of space required on disk. In particular, since any write I/O that is smaller than a sector requires a read-modify-write operation, applications currently choose to either write metadata corresponding to several portions of the disk into the same sector, or write each unit of metadata to a different portion of the disk. The disadvantage of the former method is that it is necessary to lock out several other I/O operations that would share the same metadata sector during one non-overlapping I/O operation. The disadvantage of the second method is that for substantial amounts of metadata, the amount of disk space required to store it is unacceptably large. Another disadvantage of existing systems is that it is often necessary to refer to data that has been previously persisted to disk. For instance, if a change is required on a sub-sector level, a read-modify-write operation may be needed.
It is with respect to these considerations and others that the following disclosure has been made.